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(57) Methods, eysrems, and a program, are dis- 
closed for perfonminfl electronic transactions that in- 
cludes the feature of a thin" consumer's wallet by pro- 
viding issuers with an active role in each payment. This 
Is achlev/ed by adding an issuer gateway and moving 



thacredit/debit cardauthorization function trom the mer- 
chant to the issued TWs enables an issuer lo independ- 
ently choose alternate authenticallon mechanisms with- 
out changing the aequlier gateway, li also reaune In a 
significant reduction in complexity: ihereby Improvrg 
the ease ol Implementation and overall performance. 
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DeBcriplion 

100011 The invention disclosed broadly relates locompuiei networks and more particularly relates to election icccm- 



S [00021 Electronic commerce is propcted togrow at a high rate and Oiis will have a significant mpaclon ihefinancal 
Industiy Esllmates tor 1998 aie 700 million dollars worth of lolal revenues. Future growth promises SI tollllon by zom 
No financial insiitution will be lett unaHocied by ihe rapid growth ol electronic commerce One obstacle that can tmni 
this growth, however, le the lacK of secure eleetronic paymenle Consumers and merchants are ««ty of transmmmg 
their payment informailcn over open netwoiVs such as the internet and this caution affecie the interest of merchants 

re and linancial insiitutionE ^ ^ , _ . . „ ,_ 

100031 The technoioay ol electronic commerce has adopted a number oi terms that need to be defined m onJer lo 
discuss the prior art and the invenilcn. A shoil glossaiy cS such terms follows. 

Acquire. - The financial inatitulioo (or an agent o( the Gnandal inslilution) that receives from the merchant the 
financial data relaUng to a iraneaetion and auihorizee the uansaoUon. IHe acquiring Instiiuilon can aci as lis own 
merchant certiTicale authority (MCA) oi can conlraci with a Ihiid party foi service. 

Authenilcation - in computer secuidy. Ihe process used to verily ihe Idemlly d a user or the usei-s el^jlDility to 
access an objeci; verif icaoon ihal a message has not been altered or corrupted: a process used » venf y the user 
ol an irJonnation system or protected resources 

Browser • A computer program that allows a user to read hypertext messages such as HTML pages on the World 
Wide Web 

2S Cardholder - A person who has a valid paymenicard accooniand ueee software that supports electronitcommerte. 
Also knovwi as a shopper, online shopper, consumer, oi buyer. 

Certificate - A document issued by a trusted party lhat sewes as physical evidence of ihe identity and privilege 
Ol the holdei. Usually used as synonymous with an eleclronic certificate or digital certificate since an actual doc- 
» umenl is ol liUe value m a vimrld of eleclronic commerce. 

Cenir«ateauihority lCA).anorflaneat.onihat issues certrfwaie* The CA responds toiheactlooso^^ 

Auihoriiy (RA) and issues new eertifioaiee, manages existing certificates, renews enisling certificates, and revoKes 

een ificales belongina w users w*to are no longer authorized io use ihom. 

^ Cenincate chain • a hierarchy o« tnjsted digital certificates that can be 'ohained- or awhentieated back to the 
•chain's" ulUmate tnist tevel- the lop of Ihe hierarchy caOed Ihe "roc* certificate." 

Digital eeitificaie - aneleclronie document digitalV signed bya imsied partj^ The digital certTeate bintfe a person's 
40 or entity's unique name to a public/private key pair. 

Digital signature - In me context of SET Secure Electronic Transaction progiams. data thai is appended to oi e 
a cryptogiapic transloimatwn of, a data unrt. Digital signaiure enables the -ecpent of the data unit lo venly the 
source and integrity of the unit and lo recognize poleotwl forgery 

^ Di9ltalv«lletorConsumerwaiiet-Enc.yptKinsdiwareihatwort^6i*eaphy6icalwalleldurin9eloctronicco^^^ 

transactions A wallet can hold a users payment .nlom«t.on. a dig«al ceftJioaie lo identity the user, and shipping 
Information to speed iransactions THe consumer benefits because his or her informaiion b encrypted against 
piracy and because some wallets wil aulomatioally input shipping information at the metchant's site and will give 

so Ihe consumer the option ol paying by digital cash or cheque. Merchant benefit by recclvinfl proieclion agaml 
fraud. The wallet is used to pwtecl and store cedit/debii information, protect the liansmwsion ot lhat intormaion 
lo only Ihe people that are authorized to see it and digiially sign purchase requests. 

issuer - a llnandal msUlution lhat Issues payment cards lo Individuals. An Issuer can acl as its own cardholder 
u cenificale authority (CCA) or can contract wlih a ihlrd party lor the senric© 

Key pair • In computer secunty. a matched set ol public and private keys. When used lor encryption, the sender 
uses the public hey hall to enciypi Ihe message, and the recipient uses the pnvale key half to decrypt the message. 
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When used for signing the signer uses the privaie Key helf to encrypl a repres niaiion of ihe meaaase and the 
recipient uaes ihe public key hall lo decrypi ihe lepresentaiion of th rrteesage lor aignatuie venficabon. 

Merchant server - a Web sers/er thai offers caialogued shopping services. The equwalent to a physical siore. 

* Password - For computer or r^etwork security; a specific string ol charade.^ entered by a user and aulhenll^ted 

by Ihe system in deierminng ths privileges., it any. lo scc&es and manipulal© the data and operations ol tHe 
system 

JO Payment card - a credn card or debit car^ (a) that is issued by a financial institution and shows a relaiionship 

between the carOioWer and the rinancial inslituiion and (b) for which a certtficaie can be issued iicm an auihen- 
Itcaied cenificaie authority 

Regiatralion authority (RA) - An organization or person authorized or licensed to auihsnticaie a certificate requeat- 
15 er*a idenUiy and ihe eervicee thai ihe reciuesier ia ihen authorized to use. THe RA approves requests so that 
certificates can be issued renewed, updated or revoked by a C A. The RA is usually a credit officer ol an issurg 
or aoqiiiring bank and approves the ceniticaie reouests lor us members. 

Secure Sockets Layer ■ A purity protocol that allow tliociienl loauth^npcaie the een^er and a » data and requests 
to lo be sncrypisd. 3SL otters a very limited trust model and a secure hnk between client and server 

Thin wallet • generally the digital wallet program resales on the users PC, but a "thlr^- wallet is placed on the card 
issuei-s sender, thereby reducing the program size on the users PC and enabling an easier moditicatior^ oi the 
wallet's features. 

25 

Trusted Root - the base or lop level certificate that prcvidea the basis lor the trusted hierarchy. 

[00041 The prior art SET Secure Electronic Transaction TM (trademark and service mark owned by SET Secure 
Electronic Transaction LLC) protocol has been developed as a method lo secure bankcard transactions over pubi*: 
:fO networks. SET ts an open standard, multi-party protocol for conducting secure bankcard payments over the internet. 
SET provides message intagriiy. authenticaiion of all financial data, and encryption ol sensiiiv© data. 
[0005] SET IS a 3-party protocol Involving a cardholding oonsumsr, a merchant, and a paymem gateway operating 
on behalf ol ths acquiring bank, as shown in Fig 1 When a consumer is ready lo buy something Irom a merchant on 
th« inismet usingacreda ordel>il car^. the consumers compuier 1 02 sends a consumer paymem request ovennterne 
35 path120lothemerchanr8computer104ir^afirststep The merchant's computer 104 forwards the consumers payment 
re<juest over intemei path 122 dortng a second step to an acquirer gateway 105 operating on behalf of the acqutrsr 
bank lOe The acquiier gateway 1 06 passes the consunrter's payment request to the acquirei bank 1 09 over a private 
network path 12^. TTie acquirer bank 103 sends the ccnsumer's payment request to the card iaauing bank n 2 over 
the private netvw>rk path 1 24 to check whether the consumer's credit or debit card account is active and sulTie lent for 
40 the proposed transaction with the merchant. The issuing bank ii 2 as the card issuer authorizes the transaction in a. 
message sent over private palh 126 to Reacquiring bank lOS. The acquiring bank 106 sends the transacts author- 
ization over pnvaie path 1 2fi' to the acquirer gateway 1 0S, signr g tne message with me acoulrlng bsink s digital sig- 
nature The acquirer gateway lOO lormn^s it over Iho internet path 1 28 to Ihe merchant, authonzing the merchant to 
proceed with the transaction Once the merchant has received ihe transaction authorization from iho acquirer gateway 
4$ 106 the merchant completes Ihe sales transaction with the consumer. Then later, the merchant sends a message over 
internet path 1 42 to the acquirer gateway \ OS to capture the transaction and get paid The acquirer gateway then sends 
a payment message over the 144 to the merchant The acquiring bank 108 may parlcipate m some or all oi the payment 
steps over private network paths 1 42' and 1 44'. men. at the end of the business day the acquiring bank will settle 
accounts with the issuing bank 112 over the private network. 
50 [oooei It is currently not possible in the SET protocol to provide a nhin' wallet feature since issuers do not have an 
active role in each payment. Nor is it possible for an issuer to independentV choose alternate authenlicai.on mecha- 
nisms wilhoutchangrig the acquirer gateway As with any system, it would also bedesirable to simplify the SET protocol 
in Older to enable its easier implementation and lo improve its overall performance. 

I0007I Accordingly the invention provides a method for peilorming electronic transactions over a oompuier network. 
« comprising- sending Irom a merchant's computer over an internet network to a consumers computer, a merchant 
message including a wallet initiation message, a merchant digital signature^ and a digital certificate from an acquiring 
bank, said wallet mitianon messace including a payment arfK>unn an order deecnption: and a timestamp; starling a 
consumer's wallet program m said cwsumer's computer in response to said wallet imtiaiion message; sendmg from 
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said consumer's computer con8un>er idenlily and auihenticalion informaiion and said merchant message, to an issuer 
gateway tor an issuing bank, verrfying al said isauei gateway said merchanVa signalure to prove thai ihe consumer is 
dealing with the actual merchanl and validaling al said issuer gateway ihe meichanrs c rliTicate and Ihe acquirei s 
ceriiticate Id prove lhat Ihe merchant and issuer share a common financial atiangement: said issuer gateway venlying 
5 the consumer's account and ensuring mai funds and/or credil are available to suppori the paymeni amounL then 
authoriTing paymeni by sending over said Internet network an aulhorlzation token, an Issuers dlgiial certrflcate, said 
wallei initiation rrwssase, and a r^arence lo said consumai's credit or debit card numbon said awhorization lolsen 
includingihe payment amouni. ofder description, ttmesiamp. a random oooce plus a mefcKani ideniiJiersnda reference 
to the cor^sumefc credit or debu card number and said merchant's computer receiving said authorl7ation token and 
TC fulfillrg said order description. 

[OOOai In a tunher aspect, the invemion provides a system lor pedormmg electronic transactions over a computer 
network . comprising- a merchanfe computer for sending overan intBrnet network toa con Burner's compuier. a merchanl 
message including a wallet initiation message a merchant digital signature and a digital certificate from an acquiring 
bank, said wallet initiation message including a paymeni amounl an order description, and a limeetamp. a consumers 
IS swallei program in said consumers compuier leeponeive lo said wallei initiation message, for sending from &aid con- 
sunner's computet consumer identity and a ulhentication informaiion and said merchanl message to an issuer gatev^ay 
for an issuing bank: an issuer gaiew^ay for venlying said mercnanrs signature to prove ihai me consumer is dealing 
wnh Ihe adual merchant and validating al said issuer gateway me merchantis ceitrficale and the acquirers certlficaie 
to prove lhat Ih© merchant and issuer share a common financial arrangement: ^mJ issuer gateway verifying ihe con- 
£0 sumers account and ensunng that (unds and/or credit are available to support the payment amount, then authorizing 
payment by sending over ea^l ^temei network an authonzation token, an issuer© digital certificate, said wallet initiation 
message, and a reference to said consumers credit or debit card number: said authorizaicn token mctudrg the pay- 
ment amount order descr»)tion, timestamp, a random nonce plus a merchant rientiTier and a reference to the con- 
sumers credil or debit card number and said mei^ant's computer receiving said authorization token and f uHilSng said 
25 order description. 

[0009| I n a yet f urth er aapecl . the invenlion provides a daia processing system for perfonming eleclronic transactions, 
comprising, a eon^uler processor means for sending from a merchant's compuier over an internel network to a con- 
sumer's computer a merchant message including a wallet iniliaiion message, a merchant digital stgnaiuie. and a digital 
cerllicate Irom an acquiring bank, satd wallet initiation message including a paymeni amount, an order descrption. 
A> and a timesiamp; means for starting a consumer's wallel program In said consumers computet In response to said 
wallet initBtion rrwssage; means lor sendrig Irom said consumers connpuier consumer identity and authentication 
information and sad merchant rr^essage. to an iseuer gateway lor an issuing bank: means lor veritying at said issuer 
gateway said merchanfa signature lo prove that Ihe consumer is dealing with the actual merchant and vabdatmg at 
said issuer gateway themerchanrscefilficsteand iheaoquirerscenificateto proveihatthe merchant and issuer share 
3S a common financial arrangement said issuer gateway verifying the consumers account and ensunng that lunds and/ 
or credit are available to support the paymem amount, then authorizing payment by sending over sau imemet network 
en aulhorlzation token, an issuers digital certilicate. sad wallet initiation message, and a reference lo said consumers 
ciedii or debit card nun^er. said authorization token including the payment amount, order description, limeetamp. a 
random nonce plus a merchant idailifier and a reference to the consumer's credit or debit card number, and said 
4^ merchant's conv:)uter receiving said authorization tok^ and fuiniling said order description. 

[00101 In a yet slill further asped, the invention piwides a compuier program product, compiistng. compuier program 
code means tor sending Irom a merchant's compuier over an Internet network to a consumers computer, a merenani 
message Including a wallei initiation message^ a merchant digital signature, and a digital certificerte from an acquiring 
bank, said wa«et vitiation message including a payment amount an order descnptton, and a timesiamp; computer 
4$ program code means lor starting a consumer's wallel program n said consumers computer in response lo vraiiet 
initiation message: conyuter program code means lor sending irom said consumers computer consumer identity end 
authentication intormalion and sari merchant message, to an issuer gateway for an issumg bank: computer program 
cede means tor verffying at said issuer gateway said merchant's signature io prove that the consumer is dealing with 
the aciual merchant and vaCdaiing al said issuer gateway ihe merchant's certificate and the acquirers cenificaie to 
50 prove thai Ihe merchant and issuer share a common financial arrangement: said iasuei galeway veritying the consum- 
er'a accoum and ensuring that funds andfor credit are available to suppori ihe paymeni amounl. then aulhorizmg 
paymeni by sending over said riternel network an authorization token, an issuers digital certificaie. said waliet in iUalion 
message, and a reference to said consumers credit oi debit card number: said authorization token including the pay- 
meni amount, order descrption. ilmsstamp. a random nonce plus a merchanl dcnllfler and a refeience to the con- 
55 sumers credil or debit card number and said merchant's conputer receiving said authonzaiion token and lulfiilmg said 
order description 

[00111 In a yet stilt further aspect; the invention provides a method lor p rlormmg electronic transactions over a 
computer network comprisrg: sending Irom consumers computer to an issuer gateway lor an issuing bank, an 
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authorization request meaaage containing consunwr ictenllty and aulhenticalion information, payment amoonl an ordei 
dedcrtplion. a limedtamp. a digital certificate represent ing a merchani and a digital certiricale repreaenting the mer- 
chant's acquiring bank, said merchant's digital certiFicale conlaining a merchant idenlifier unique for the acquiring bank; 
said i^-quiring bank's digital ceniTicale containing a bank identifier unique among all banks sharing a common financiai 

5 arrangement, validating at said issuer gateway the mercfiant's certificate and the acquirer's oertibcale to prove that 
the merchant, acquirer, and issuer share a common financial arrangement; said issuer gateway venlymg Ihe consum- 
er's account snd er^wnng that (unOs ar>dfor credit an© availabi© lo suppori ihe paynneni arT>ouni, ihen authonzing 
p«)ymenl by sanding over said ini^m^i nelwork an auihonzaiion toKen, an issuer's digital certilicale: and a rsference 
to said consumers credn or debit card number said avthonzaiw loken including fhs p«yment amouni, order descnp- 

ra tion. timesiamp, a random norwe, said merchant identilief Irom ihe merchant's digital certilicate, and said acquiring 
bank identiber from said acquiring tank's digital ceniricaie. plus a reference lo the con^mer's creda or debu card 
number: sakJ authorization loken being digiialty signed by the issuing bank: arhd said merchani's compuler receiving 
said authorization token and fuinillng said order descripiioa 

[0012] According lo the preferred embodiment the consumer identity and authenticalion information may be a user id 
15 and a password, an ATM debit card nunftber and PIN. a smart cartfe account number arvJ a symmetric Message 
Aulhenlication Code (MAC) a smart card's account number and an asymmetric digital signature, a consumer's digital 
Signature and digital ceruflcate. a consumer's digiiai certibcaie and matching asynmeiric digital signature, a user ac- 
count number and a symmetric MAC or asymittetnc dlgllai signature, a user account number and an asymmetric digiial 
signature, or a consumer'^ btomelrio signal. 

[0013] In the preferred embodiment there is a digrtal cenlficate hierarchy that covera issuing banks, acquinng bank*: 
end merchants The certrficale hierarchy is ueed wih public-key digital eignaluree to Weniify said merchant and sa»d 
issurig bank The certihcaies represent common rtnancial agreements and obUgaions among the merchant and ihe 
issurig bank The issuing bank certificates idenirfy and help authenticate issuing banks to merchants, providing a basis 
for the merchants to irust the auihorizaiton lokens provided by the Issuing banks. An acquiring bank certilicale and a 
2s merchant certificale identify and help a uihenticale the acquiring bank and the merchant to issuing banks. The merdiant 
certificate identifies Ihe merchant lo the consumer and verifies that the merchant is a valid parlicipanl of a payment 
scheme belore the isduing bank provides said authorization token. 

[0014] Thus electronic transactions can be performed, in accordance with a preferred embod indent of the present 
invention using a thin" consumer's wallet by pioviding issuers with an active rc»ie m each payment. This is achieved 
^ by adding an Issuer gateway and moving the credll/debit card authorization lunctlon Irom the meichant to the &suer. 
This enables an issuer to independenily dx)0£e a&emale autheni cation mechanisms without changing the acquirer 
gateway it aleo results In a significant reduction m complexity, ihereby improving the ease ol impienneniaiion and 
overall perlorvr^ancs. 

[0015] According to a prelerred embodiment, the method ol Ihe invention includes the step ol sendmg irom a con- 
^ Burner^ compuler a siart message over an internet neiwork lo a rrwrchant's compuler The merchant's computer then 
replies tc ihe consumer's computer wiih a merchant message irtciudlng a wallet initiation message, a meichani digital 
signature, and a cfigilal certificate from an acquiring bank. The wallet initiation message includes a payment amounL 
an Older description a timestamp. and a nonce. This starts a consumer's wallet program in the consumer's computei 
in response to the wallet initiation n^essage. The consumers computer then sends ovei the inlemei network some 
^ consumer identity and authentication inlomi^tion, such as a useiid and user password, plus the merchant message, 
to an issuer gateway operating on behalf of an issuing bank. 

[0016] The issuer gateway verifies the merchant's signature to prove mat the consumer is deaing wlih the actual 
merchani and validates the n^erchanl's certilicale and the acquirer^ certilicale lo prove that ihe merchani and issuer 
share a common hnancial arrangement. The issuer g«teway then verifies lhal the consumer's account is active and - 

-^S has sufficient lunds and/or credH lo support the paymeni amount The issuer gaieway Ihen auihorizes paymeni by 
sending over the internet network an auihonzaiion token, an issuer's digital certificate, the wallet mitwtion message, 
and a reference value representing ihe consumer's credit or debit card number The authorization token includes Ihe 
paymeni amount, order description, timestamp, a random nonce plus a merchant identiiier and the reference to the 
consumer's credit or debit card numl^er. The issuer gateway signs the authorization token. This informaiion can be 

^ sent either to the consumer or lo the merchant to fulfil the order description. If s«it lo the consumer, the consumer 
forwards the authorization token to the merchant The merchant vertfie » the issuer's signat ure issuer's digital certificate, 
and authorization token contents lo validate that the paymeni is authorized by the issueL 

[0017] Once Ihe merchant has leceived the authorization token Irom Ihe issuer gateway Ihe nr*erchant completes 
the sales transaction with the consuiner. The merchani may choose whether to do the authorization In real time (whQe 
55 the consumer wans) or later Then later, the nrorchani sends a message, irKiuding the relerence value representing 
the consumer's card number, over the internet to an acquirer gateway operating on behail ol an acquirer bank, to 
capture the transaction and get paid. The acquiring bank will settle accounts with ihe issuing bank over a pnvaie 
network by sending a settlement message lhal includes the relerence to the consumer's card number. The issuing 
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bank will convert ihe refeience value inlo Ihe consumer's card numbet and apply the uanaaction amounl lo ihe con- 
sumer's balance in hia credit card oi depceil account 

10018] irthelransaclion is laier disputed, the merchant can prove rhal the issuer authorized Ihe payment by producing 
a copy ot the auttvsrizaiion lokea The coiir*inalion ol the issuer's signature on the author izalion token, ihe issuers 
* digital certiticale. and the oontenis o( the aulhorizatwn token provide undeniable prool lhat the issuer aulMorized Ihe 
paynnenL 

[0019] li privacy is dssirod: ih© communicaiion among \h9 con^unrt^r vraliat, issuer gaieway. and rrorchani can be 
protected via ih© Secure SocKel Layer (SSL) protocol SET vtras designed for both Wsb and em«il us&. The stan and 
wallei inrtiauon meeeages described above would not be used rn an email impiememation. however, the resi w as 
JO previously descnbed The contenis of the wallet initation message in an emad implemeniation conrtes trom another 
source, such as a CD-ROM. in which case, it could not be signed 

[00201 In this manner, a 'ihin" wallet is enabled for the consumer in an electicnic commerce protocol that is signffi- 
cantly sinpter ihan the SET pioiocol. ihereby improving overaD performance and enabling greaier flexibiliiy for issuer 
in Ihe auihenticalton of cardholders. 

js [00211 A preferred embodlmeni ot the present invcniton further provides a nnaneial instilution's digital certificate 
oontainrig a nelwork address or UFIL ihal Idemifies Ihe nelvuork location ci the financial inslilulicn contacled via an 
Inteinei network as part ol a payment protocol. This can be applied to boih uie issuing bank and the acquiring bank. 
[0022] A preferred embodiment ol ihe present invention will now be described m detail, by way of example only, wiih 
relenence to the lollowing drawings: 

^0 [00231 Figure 1 illuslrates the prior art SET Ihree-party protocol. 

[0024] Figure 2A iihjsiratea (he icur-party prc^ocol, in accordance wim a prelerred embodimeni oi the present inven- 
tion 

(00251 Figure 2B iliusirates the rouie ol Ihe authorization loKen m me lour-parly prolocol. m accordance with a pre- 
ferred embodiment of the present invention. 

[0026] Figure 2C illustrales the use of a consumer's snvirt card in the fouriaarty prolocol. in accordance with a 
preferred embodiment of ihe presenl invention. 

[0027] Figure 3 is a flow diagram of Ihe four-party protocol, in accordance wilh a prefen-ed embodimeni of the p resent 
Invention. 

[0028] Figure 4 dluslraies a variation m the lou r-party prolocol. wherern Ihe signed auihorizalion token is sent direclty 
» to the r¥»rchant, m accordance with an alternative preferred embodimeni ol ihe present invenllort. 

[0029] Figure 5 illuslrates the four-party prolocol as Applied to a pluraliiy ol issuing banks, in accordance wiih a 
preferred embodiment oi ihe preseni nvention. 

[0030] Figure e aiustratee the lour-faarty prolocol as applied tea plurality ol issuing banks anda pluraWy ol acquinng 
bflnkS: r» accordance wilh a preferred embodimeni o( the preeept invent ion 
^ [0031] Figure 7 illustraies Ihe issuer gateway processor, m accordance wilh a preferred embodinfwm ol ihe present 
invention. 

[0032] Rgure 8 is a flow diagram of the issuer galesuay process in the four-party protocol. In accordance ^ith a 
preferred embodiment of the preseni invention. 

[0033] Figure 2A ilhjslrates the four-party prolocol. in accordance wilh a preferred embodimeni ot the present inven- 

40 tion. An issuer saieway b provided and Ihe credltfdebit card auihorization function i» moved from the mercham lo the 
issuer. The four-party p rwiocol method includes the step of sending from a consumer's comp uler 202 a start messages 
220 over an internet network to a nrterchanrs computer 204. The merchanl's oompuier 204 then replies to the consum- 
er's computer 202 vwih a merchant message »Tcluding a waHel inrtiabon message 222: a merchant digital signalure, 
end a disilal cert if icaie from an acquiring bank 208 The wallet initiation message includes a paymeni amoum. an order 

4$ descnpiin, a nmesiarrp, and a nonce. This starts a consumer^ wallet program in the consumers computer 202 in 
response lo the wallei initiation message The consumers cwputer 202 ihen sends a message 224 over the internet 
netvwrV including some consumer Idenliiy and aulhentication infonnaiion, such as a userid and user password, plus 
the merchant message, loan isetier gateway 214 operaiing on behalf of an issuing banii 212. 
[0034] The acquiring bank's digital cerlificate can contain a netvtcrk address or UFtL that identifies Ihe nelwork lo- 

50 cation of the acquiring bank conlacted via an internet nelwork as part of a paymeni protocol. 

[0035] In Ihe preferred eittbodinftenl Ihe issuer flaleway 214- verifies the merchanl's signature lo prove lhat the con- 
sumer is dealrifl v*ith ihe actual nfterchant and validates the merchant's certificale and the acquirer's certiTicale lo prove 
thai the merchant and issuer share a common financial arrangement. The issuer gaievuay 214 then ver^ies lhat the 
consumer's account Is active and has sufficient funds and/or credit to support Die paymeni amount. Then, as sho^n 

55 In Figure 2B, ihe issuer gateway 21 4 then auihorizes paymeni by sending over the iniernet nei wrK an authorizaiion 
token 254 over path 226, an issuer's digiial certificate, the \wallet initiation message, and a relerence number or value 
252" representing ihe consumer's credit or debu card number. The reference number 252* is created by the issuing 
bank 2i 2. for example by preparrig a lable or credit card or deb* card numbers 250 and a corresponding table of 
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releience numbei 252. The iseuing bank pairs Ihe conaumer'a caid number 250 wilh a aelecled reference number 252 
end ouiputa the reference number over paih 226' to ihe issuer gateway 214. The iesoet gaieway then includes the 
relet nee number 252' with the authorization token 254. The authortzaiion token 254 includes ihe paymenl an¥>unl, 
order description, llme&lamp. a random nonce plus a meichanl idenlifier and Ihe reference number 252' to ihe con- 

5 sumer's credit or debit card number. The issuer gateway 21 4 signs Ihe authorizalion token 254 on behalf ol Ihe issuing 
bank 21 2. This Inlonnallon can be sent erther to the consumer 202 over path 226 as show In Figure 2B. or direclly lo 
the mencliant 2CM cvsr path 402 as shown m Figure 4: lo fulfil the ord&r doscripiion H seni to the con$unw 202 In 
Figure 2B: Ihe consumer fonwards ths auihonzailon token 254 to Ihe merchant 204 over path 22S, as shown m Figure 
2B The merchani 204 venlies the iesu8f's signature, issuers dignal certificate, and authonzsuon loiwn contents to 

TO validate Ihat the payment is authorized by the issuer 21 2. 

[0036] The Issuing l>anK's digital c ernficate can contain a network address or JRL that identifies the network location 
of the issuing bank contacted via an internet network as pan ofa payment proioool 

[0037] Once ihe merchant 204 has received the authorization td^en 254 from ihe issuer gateway 2i4. the merchant 
204 completes the sales iransaclion with ihe consumer 202. The merchant 204 may choose vnhether to do the author- 
is i2atlon in real lime (while the consumer 202 wails) or later. Then later, the merchani 204 sends a capiure request 
messages 256 over path 242. tnclucfinglhe reference number 232' representing the consumer's card number, over the 
Imernei lo an acquirer gateway 206 operaiing on behalf of an acquirer toanK 208, lo capiure the iransacion and get 
paid. The acquiring bank 20S will settle accounts vnlh ihe Issuing banii 21 2 over a private network shown n Figure 23, 
by sending a ©©tllcment message 268 that includes ihe relerence number 252* to tlia oonsun^or's card number The 
£0 i^sung bank 21 2 will conven the relerence number 252* into the consumer's card number 250 fmd apply the transaction 
amount to the consumer's ttaiance in his credit card or deposit account 

[00d8] II the transaction is later disputed, the merchani 204 can prove that the issuer 212 authorized the payment 
by producing a copy of the authorization token 254 The combination of the issuer's signature on the authorization 
token, the issuer's digital cenificate. and the contents o« the authorization token provide undeniable proot lhat Ihe issuer 
£S flutl^rized ihe paymenl. 

[003^ If privacy is desired, ihe communicaiton among the consumer wallet, issuer galeway. and merchani can be 
protected via ihe Secure Socket Layer (SSL) piotocol. 

[0040] Theaboveapptioachcanbeappliedtoboih the inteinel World Wide Web andloemail use. The start message 
220 and waliel initiation message 222 descnbed above would not tDe used n an email implementation, howevsi the 
A) resl IS as previously descried. The conlenis ol the wallet mitiation message in an email nplsmeniaiion comes from 
another source, such as a CO-ROM. v) which case, tl couti not be signed. 

[0041] In this rrwnner, a *ihin' waiiet is enabled for the consumer in an electronic con^meice protocol that is signifi- 
cantly ampler than the SET protocol, thereby improving overaO peiformance and enabling greater llexibilily lor issuer 
in the authentication of carctioiders 

3S [0042] Figure 2C illustrates the use ol a consumer's smart card r the lour-party protocol, in accordance with a 
preferred embodiment of the present invention. The sman card 262 owned by theconsumer can be used to authenticate 
the consumer lo the issuer gateway. When the consumer's computer 202 sends an attempt message 272 which at- 
tempts loconneclwHh ihe issuer gaieway 214. ihe issuer gateway reepondaioiheconsumei computer with a challengs 
message 274. The consumer computer 202 then passes Ihe challenge on lo The smart card reader 260, which passes 

40 it on as Ihe challenge 274' lo the smart canJ 262. The smart card 262 then signs the challenge wiih it digital signature 
and returns the signed challenge response 276 tothe consumer's computer 202. The consumer's computer 202 then 
combines me signed challenge response 276 wnn ihe merchanrs initiation message 224 and sends it on to me issuer 
gateway The issuer gateway 214 verifies the smad card's signature and thus verifies (he consumer's identity 
[0043] It IS possible to choose from a variety of methods to perlonn authentication ol Ihe consumer with the issuer _ 

4$ gateway 2l 4. Examples nclude a userid and a password, an ATM debit card number and PIN; a smart card's account 
number and a symmetric Message Authentication Code (MAC), a smart card's account number and an asymmetnc 
digilal signature, a consumer's difftal signature and digital certificate, a consumer's digital certificate and matching^ 
asymmetric digital signature, a user account numter and a symmetric MAC or asymmetric digital signature, a user 
account number and an asymmetric digilai signature oi a consumer's biometric signal This wide choice of authenli- 

so cation methods between the consumer and the issuer gateway is possible because issuers have an active role in each 
paymenl. This enables an issuer to independenUy choose allernale auihenlicaiion mechanisms without changing the 
acquirer galeway 

(004^ Figure S is a fbw diagram 300 of the four-party protocol in accordance wilh a preferred embodiment of the 
present invention. It begins wUh step 302 where ihe consumer presses the "pay" butlon on the n^erchant's HTML 
55 intemet browser page to send the «tari message to the merchant Then m step 304^ the merchant sends to the consumer 
the wallet initiation message with the payment amount, order descnption. timesiamp, and nonce The merchant signs 
th© message snd includes a digital certificate irom th acquiring banK Then m step 30S, the consumer's wallet is 
started, the consumer logs on, and the user's identilicalion and aulhenticalion Inlormalion and the merchant's initiation 
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messag aie sent to the issuer gateway. Then in atep 308 ihe issuer gateway verifies the nnerchanrs signature to 
prove lhat ihe consumer is dealing wilh the aciual merchant, validates ihe merchant's ceriificate and ihe acquiiei's 
ceriificat to prove lhat the merchant and issuer share a common financial an-angement. Assuming lhat the issuer is 
hap py tor ihe payment to proceed in view of ihe funds available lo thai consumer, then in slep 3 1 0. Uie issue r ^aleway 

5 authorizes payment by sendrig over ihe ritemei network an authorization loken^ an IssueTsdigilal certificate, the wallet 
Inlilation message, and a reference to the consumers credll or debit card number Then In slep 31 2, ihe authorization 
token including the paymeni amouol, order description: timwiamp, a f?jndom nonce plus a mefchanl identlli^rand a 
relerence Ic the consumer^ credil or debh card number are forwarded to Ihe merchant Then later in slep 314, ihe 
merchani submrts the authorlzaiion loken m 9 capture request lo the acquirer bank Then rn siep 31 S, the acquirer 

10 bank settles wilh ihe issuer bank 

((KMSJ Figure 4 illustrates a varistloo m the lour-party protocol, wherein ihe signed auihonzaiion token is sent directly 
to the merchant on path 402 and the merchant sends a conlirmalran message 41 0 to the consumer 
[Otwe] Rgure 5 lllusirates the tour-paiiy proiocol as applied to a plurality of issuing banKs. in accordance wilh a 
preteiffid embodiment of ihe present invention. Here a plurality of Issuing banka 21 2A. 21 2B. and 212C can commu- 

75 nicate ovei privaie networks with a common issuer gateway 2i4. 

[00471 f^9u>*fr ^ illustrates the four-party proiocol as applied to a plurality of issuing banks and a plurality of acquiring 
banks. Here a pluratiiy ol issuing banks 2i 2A. 2i 2a and 2i 2C can communicate over private networks wilh a common 
Issuer gateway 21 4 and a plurality ol aoqulrng banks 20SA. 20S& and 206C can commumcale over private networks 
wrth a conrmion acquirer gateway 20S 

iC [004$] Figure 7 illustratee ihe issuer gateway procee«oi, r accordance wilh a preferred embodimem ol ihe present 
invention. The processor 7D0 indudee a memory 702, a bue 704, a CPU processor 708, and m issuer gateway trans- 
action manager base switch 770. The base switch 770 includes a froni-end that mcludee a Iront-end local sender 774. 
a Ironi-end HTTP server 776, and a ironi-end TCP server 778. The base swilch 770 rncludes a back-end lhat includes 
a back-end UNIX client 760, a back-end TCP/IP client 782. and a back-end LU6.2 client 7S4. A router 772 connects 
the front-end to the back-end. The tronl-end ie connected to coneumere 202 and the back-end ie connected to iseuera 
212. The memory 702 includes issuer "A' inierface buffers 730. issuer "B' interface buffera 740. the lour-party credit/ 
debil paynrkeni protocol program 750. Iront-end eerver communication prolooois 752. back-end ciienl communication 
protocols 754, and Ihe operating system 756. The programs stored in the m^nory 702 are sequences of executable 
instructions which when executed m ihe CPU 708 perlorm ihe methods desaibed al:ove. 

40 [0049] Frgure 3 is a flow diagram 900 of the ssuer gateway process In the lour-party proloeoL in accordance vwlh a 
preferred embocfiment of the present inveniion In step 602, the Issuer gateway receives the consumer's credit request. 
Then slep S04 auihentic»tes Ihe message ueinQ the ccnsumefe ueend and auihenncation informailon Then step S06 
authenticalesihemerchani's wallel bitlalion message using the merchant's public Key and digital certihcale. Then slep 
60d confirms that the consumer's credh or depoea is sulticieni lor the transaction Then step 8i0 accesses Irom Ihe 
Issuer a consumer relerence number correspondirig to the consumer's credil card number. Then slep 81 2 generates 
an aulhofizaitontoi(en signed with the issuers signature using a private key and digital cenitlcate Then step 814 sends 
to the consumer's v^allet the signed authorization loken and the issuer's cenificate, with ihe wallet iniiiaiion message 
end the consumer's card reference number. Then step 8i 6 sends a confirmation to the issuer. 
[O05O] The approach described atiove has many advantages. 11 fits weH wilh sen/er-based (thin) wallets (which op- 

^ eraie in the issuer gatevways). Ii separates ihe autheniication technology used between ihe consumer and issuing bank 
from the remainder of ihe payment pmlocol. Il permits each issuing bank lo determine how il will authemicate its 
consumers f e.g. userrd/pasevuord. symmeinc oi asymmetric keys with or wlihoui digital certlficaies or smart cards, or 
other security hardware ) It avoids the use ol digital certificates for consumers. It el»nriates Ihe oosi and delay ol real- 
time authorization through the private network between the acquirer and the issuer It reduces overhead lor merchant 

-♦5 and payment gateway, since payments ar© authorized before they reach the merchant and since much less cryptog- 
raphy is required. It provides proleotion for the credil or debrt card numbec without using encryption. Il comphes wilh 
U S. expon taws arkd loreign cryptography usage laws by not using any encrypiion it has potential lor lower develop- 
ment and testing costs ^compared to SET) because of a simpler design Examples of the simpler design indude avoid- 
ance of encryption; eliminalioo of ihe requiremenl for consun^r certificalea; and avoiding any requirement tor the 

so consumer wallet lo validate cerllticatea, generate digital signatures, or verify digital signatures. The invention supports 
Japanese Payment Options and other issu^-based payment features in a manner simpler than SET 
[O0S1] A more detailed d'^ussion of ihe proiocol steps follows: 

1. In Figure 2A. path 220. Ihe consumer uses a browser lo shop ala merchant WWW slie. The consumer presses 
« a *p«y' buiion on the meni^iani's HThAL page, orotherwise indicates that the consumer is ready tonwke a payment. 

In Figure 2A, path 222, the Merchant sends a wallel initiation message to the consumer, containing payment 
amounl, order descnption, timestamp: a random nonce, and possible additional data depending upon require- 
m nis. The merchant signs this initiation message and inci tides a digital cenificate provided by the acquiring laanit. 
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2. In Rgure 2A. paih 224. lh& WBllel iriitialion measage cauaea ttie consumer's biowaer to start the consumers 
wallet The consumer is prompted to logon to the wallel using userid/passwoid, smartoard or other appropriate 
aulhenlicalion mechanism. The wallel sends data from slep 1. plus the consumer's identity and authenticalion 
data to the issuer gateway. 

5 

3. In Figure 2A, path 226, the Issuer gateway verifies the merchant's signature and digital ceitltlcate to validate 
ihai the merchant and issuer ^ar© a common financial anrangemeni ©siaWished by naicnai law or financial as- 
socialion«uch as MasterCard, \Asa, an ATM rwtworK, or simiUir organ izal Ion. The issuer gaieway aulhorwas psy- 
meni via ihe issuer's credit card processing sysiem. The issuer gateway general es and sends a signed auihon- 
zaiion token lo the consumer wallet, along with the issuer gateway's cedificate The authorization token contains 
Ihe (lata from step 1 plus a merchant identiiierand a relerencetothe consumer's credit card number, The Veler- 
ence" is discussed l>elaw in more detail 

Note lhai the auihorizaiion token is "bound* lo the panlcular payment by the reference to the conauirter's credit 
card numl>er, merchant idenlif ier. payment amount . timealantp. and nonce. This means that a apecilic authorization 
75 loken is good for ]usi one payment 

4. in Figure 2A, path22S, the consumer's wallet totwards the autnoiization tok^ id the merchant, whicncan verify 
both the issuer gaiewuay^s signature and the data In the aulhotizatlon token. No separate realtime authorization is 
required since the payment Is "pre-authorized' before il reaches Ihe merchant 

5. In Figure 2A, path 242, at some later time, the merchant sutjmits the authorization token in a capture request 
10 the acqgirer'B paymeni gateway The capture requests lells the acquirer to actually post the charge to the con- 
sumer's creditor debit aocourn Coniidentiatlty of these messages can be olJtamed. if desired, by transmitting them 
within SSL sessions "Rie integrity and auihentkjiry of the messages does not depend upon SSL so that the mes- 

25 sages can be ueed lM>th loauthorize ongoing processing stepa and to provide proof thai ihe transactions occurred. 

[0052| Note that Ihe consumer wallet software necessarily providea very liille function in this design. Most of ihe 
payment protocol function is performed in Ihe issuer gateway. At minimum, the wallet provides some method of au- 
theniicatmgthe consumer lo the issuer gateway, as discussed betow. il consumer wallets are shared anr^ng issuers, 
A> then Ihe aulhsnticauon scheme must be shared, bui the authentication data (e.g. smart card) could be diflerent lor 
sflch issuer II consumer wa Bets are not shared among multiple issuers, as shown m Figure 5, ihen theautlientication 
mechanism (sman card, userid^assword) couki be diiferent for e^h issuer 

[0053] The consume r wallst m uet provide paymeni request l imeout and retry f utki ions Most other functions can be 
placed if^ either the consumer wallel for the issuer gateway These include most of the user interface, the payment 
^ inquiry function, the payment liansacllon log suppon for multiple consumer cards, and support for paymeni selection. 
Irr^lementinQ these functions at the consumer machine wouW result in a 'taf Nwallet: implemgnting them in the issuer 
gateway woukJ reaull in a "thin" wallet. 

[0054] Message proceaaing functions (paraing and checking incoming nnessages, generating complex outgoing mes- 
sages) are nwch simpler than in SET. since no ^cryption is used, the wallet need not examine the merchanfs data 
40 in atep i and ihe authorization token from step 2: and the wallet neither generates nor verifies signatures. 

[005(5] The merchant, acquirer gateway, and issuer gateway should implement replay delectbn both to handle error 
retries and to defend against malicious replay auacks. 

RefererH:^ to Credit/Debit Card Nunr^er 

4$ 

[0056] At protocol step 3, ihe issuer galeway includes a Velerence* to the consumers card number m the authorization 
token 11 the actual card number were used, the authorization loken-or at least the card number-would have to be 
encrypted in protocol steps 3. 4, and 5. instead, the 4-party protocol uses a "reference", which can be composed In 
either of the following ways. 

so 

a. The reference ia an "alias card number* nneaning a secondary account number thai ia mapped at the issuing 
bank to the real card number. This is similar to an approach discussed (and rejected) dm ing the SET design, and 
actually used in the X9.S9 ANSI draft. The alias card number is only used for tntemet-based transactions that are 
accompanied by an authorizabon token. A stolen alias cam number has no use without an authorization loken, so 
It cioes noi entail any risk to real-world credit cards 

b. The reference Is an authorization number allocated uniquely by the issuer gateway for each authonzatioo This 
authonzation number is passed by the acquirer galeway bach to the issuing t>anlt in the capture message The 
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i&euing bank maintains a dalabase mapping aulhorization nunnbera lo card numbers. When (he issuing bank re- 
ceWe^ the capture imeasa^e. it uded this database mapping lo delermine the actual card number. 

[00S7| To Support Ihis design, (he aultvsrization token would include a dumnmy card number for use in routing the 
^ paymenl to the appit)priale issuer. This dummy card number could be shared among ail cartfliolders using this 4-paity 
protocol. EiUier of these alternatives can support Inlerfacing lo the existingcaptuie networks thai nteiconnecl acquiring 
and issuing banks 

C&rtificats Hierarchy 

w 

(0059] Th9 ^-party protocol is supported by a cenincato ruerarchy thai covors issuing banks, aoquirrig batnke. and 
merchanis, Tbe cenincale hieiBrchy is used with standard asymmelric (pubUc-key) digilal signal ures to Ideniify Ihs 
protocol participants to each cthet The certiTicaies represent (he common financial agreetnenta andobOgaiions among 
these parties. In particular, the issuing bank certificates ideniify and help authenticate issuing banks to nterchanla, 
providing a basis tor the merchants to trust ihe authorization tokens provided by the issuing ban ks. The acquiring bank 
and merchant certiTicaies ideniify and help auihenticale ihe corresponcfing participants to issuing banks. This serv/es 
several purposes, (a) identiR^ the merchant to the consumer, (b) venftes that me merchant is a valid participant of 
the payment scheme before the issuing fctanks provides an authenbcallon token, (c) helps deter some lorms of attack 
on issuing banks by requiring pariicipation gl both a consumer and merchani in an attack. Th9 cortificai^ hierarchy is 
iHusicated in the lol lowing labia: 



TABLE I 





CeniltcateType 


Purpose 


issuing Party 


Relying Parties 


2S 


Root 


Provide trust base lor entire protocol 


Boot (self) 


All 




Issuing bank 


Identify 6 h^tp authanttcal^ vatkJ issuing tianKs 
to merchants 


Root 


Merchant. Acquiring bank 


SO 


Acquiring bank 


identify & help authenticate valid acquirers to 
Issung banks and consumers. 


Root 


issuing t^nk, consumer 


35 


Merchant 


Identify 4 halp authenticaie valid merchanis lo 
issuing banks and consumers. 


Acqinnng BenK 


Issuing bank, consumer 



[OOSd] Consumer certificates are not required, since the consumer authenticates to the consumer's own Issuing 
bank. The consumer and bank have a long-term established relationship, so the bank can keep the symmetric or 
asymmetric key required to auuientk^ate the consumer. 

[0080] X.S09 or Other establish sd digital oertilicate formats are used. Each certificate tdsntifies the certiricate ownsr 
byname, physical add rase, network address, and so forth, in particular, the Issuing gntevvay'scenificate should contain 
the issuing gateway's netv^ address to support split, recurring, and instaimeni paymenis as described bei&w TTie 
merchani'8 certificate should contain the merchani'e name, address, and contact inloomation lo assi^ dispute resolu- 
tion TTie merchanr'6 ceittticato 6lx>uld identify the acquiring bank that hold the mefchanTs business account used to 
settle parymertTs. 

[0061] The certrticate hierarchy is rooted by an authority joirtri/ trusted by the banks The root could te run by indi- 
vidual credit or debit brand associations, such as MasterCard. Visa, or the ATM network associations, by a natbnal 
regulator such as the Federal Reserve; or by an mternatlonai organization such as ihe WTO or World Bank. The choice 
of who runs the root Is associated with the queston ol who establishes and enloroes the business and regulatory 
arrangements between the Issuing and acquiring banks, if national or International commercial laws define these ar- 
rangements (as Mith paper checks), then a public Ofgaruzatlon would be appiopitat^. II private bi -lateral or multt- lateral 
banking contracts dsf in e thd&earrdngemenls. Ihen financial a&soc^t ions {such as MasterCard or Visa) might operate 
the root Th« organ i^attor ol the cenificate hieraoihy should reflect ih9 business arrangonr^ts PoestDle arrangements 
could include separate hierarchies for separaie countries or francial asscoaiions (e g, one hierarchy for Visa, and 
anothsr ror MasterCard): a shared hierarchy as with SET (e.g. an industry root ihai giants cen if icates to sub-trees tor 
fir^ncial associations or countries): or other variations 
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Consumer Authenticalion 

[O062] An advantage of this design b the fad that the issuing bank can choos Ihe technology used to authenticate 
the consumer to ihe issuer gaiewa/ Pcssibililies include niany standard techniques commor in Ihe industry. 

5 

Usend and password, for exanople as piovlded by basic authentication in standard WWW t>roMsers. 

Account number and ATM PiN 

10 Soitware- or.smart card-based symmatnc or asymmetric auihentication, where Ihe issuer galeway obtains match- 

ing koy venricatton Inlormaiion trom a database. 

Asymmetric authentication using digital certiticaiea, for example using SSL v3 as implemented in WWW browsers. 
This could be implements using either aoflware or smart carda. 

IS 

Proprielary hardware tokens. 
Biomelrtes. 

^0 [00$3] End- user authenticalion involves a complex trade-off between cosi, security, risks, portability and end -user 
convenience. Furthermore: ihe trade-ofis change war time as new ueer authentication technology ie Invented. UnliKe 
SET, the 4 -party protocol design allows individual issuing banks to nnake their own choices for their customers, inde- 
pendently ci the digital certificate technology used lo authenticate merchants to issuers, and banks to each other. 
Split Shipments. Recurring Payments, and Instalment Payments. 

2S 

SET provides the following features. 

Spnt shpments support merchants Mho must backorder merchandise. 

^ The merchant can divide a payment Into two or more portions thai are separately authorized and settled, without 

consumer interaction 

Recti mng payments support mercharvlieiog schemes such as monthly newspaper subscriptions. The merchant 
can auihonze arKi capture payments on a regular schedule, given initial consumer approval and without further 
^ consumer involvement 

Instalmenl payments permit consumers and meittiante to stretch a payment over time. Al the lime of a purchase 
ihe consumer and merchant agree lo a particular schedule and the merchant or accjuiring bank then autonnatically 
authorize and capture payments according lo the schedule. 

40 

[O064| Split shpments die supported in the 4^arty protocol by an additional message interaclion beh&reen the mer- 
chant and Issuer gateway, as shcnMi In Figure 4. When the merchant discovers mat ii needs to split a shipment. It 
sends Ihe auttiorizalKtn token Irom step 3 lo the issuer galeway identified m the issuer's digital cenificate This is a 
message on path 402, The merct^ni includes the details ol the spiM requirement, such as the amount ol the first 

4$ payment. The merchant authenticates the request by signing it and including the merchant's digital certificate The 
issuer gateway can venty ihat Ihe merchant signing message is the same merchant that signed the original request 
1, The issuer gateway verifies the split request according to its business and risk management polictes, and resporKis 
with a new authorization token in a message on path 402. Ttie merchant forwards Ihe new auihorizaiioo laken in the 
capture message on path 242 to the acquirer gateway. This message is ihe same message as in Ihe basic pir>tocol 

^ design. The merchant resubmits Ihe auihoiizalton loken in a second message on path 242, whenever the merchant 
has shipped the second pait of the shipment If the merchant needs lo further split the shipment, then messages on 
paths 402 and 242 can be repeated as needed. 

[0065] The 4^party protocol can support recu rring and instalment features by a combination of additional information 
In the authorization token, and messages on paths 402 and 242 cl Figure 4. Specif k^tiy. the steps ol the basic protocol 
^ a re modified as follows* 

1, The wallet Initiation message contains addilionalpararnetersthai identify thelermsof any recurring or instalment 
payment agreed between the merchant and consumer 
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2. The wallet should display these l&rms to ensure consumer awareness and agreerrkenl. The wallet forwards ihe 
additional paiametere lo the iaduer gateway. 

3. The issuer gateway verifies that Uie recurring oi Instatmertt Lenns are acceptable according to ihe isduei's busi- 
^ ne&s arKl risk nrtanagemenl policies. The issuer gateway includes Ihe terms as addilbnal paraineters in the au- 

Ihorlzalion tokea 

4. The con$um«f'5 wallet fonwards the eulbonzation icken (wiih additicn«l parfwneters) lo Ihe noercharii as in the 
baBic proiocol. in the ma^sag^ on paih 223 oi Figure 2A. 

JO 

5. The capture of the iirst ineiabneni or recurring paymeni occutb as wii^ the basic proiocoL \n ihe message on 
path 242 of Rgufe2A. 

6. The merchanl authorizes the second and subae^^uenl inslalmeni or recurring payments by sending ihe message 
on paih 402 of Rgure 4 to ihe bsuer ^teway. The addiltonal parameters in the auihorizailon token allow the issuer 
gateway lo recognize and appropriately handle these special paymeni types. The issuer gateway returns a new 
authorizaiion token in another mes^ge on path 402 of Figure 4 that can be used booi for captures (m a message 
on path 242 ol Figure 4) and lurthei authorizations by repeating messages on paih 402 ol Figure 4 as requiied. 

^ Japan see Paym ent Opiior^ (JPO) 

[0066] SETsuppofis a special business arrar^gementihal Iscommon in Japan Issuing banks and merchanis attract 
cuBiomere and business by oitering instalment and other payment arrangemenis that are managed by the toanks rather 
than the merchants This involves a very complex protocol among all the SET participants 

^5 [00&7] The 4-party proiocol facilitates this feature because the consumer wallet and issuer gateway <*rectly interact. 
Specifically, at step 2 of the protocol on path 224 ot Figure 2A. the issuer coukJ offer special paymeni arrangemenis 
to the consumer. These arrangemenis could be conditioned on the merchant name ( from he merchants digital certif- 
icate), the amount of payment (from ihe initiation message), or other data supplied by the merchant in Ihe initiation 
message. The remaimng steps of the 4-party proioool can operate unchanged from the base design. This considerably 

A> simplifies the JPO protocol support (compared to SET), white providing an opporlunity lor Issuers todlflerentiate them- 
selves and attract consumer business. 

Proiocol Flow Aferwtion 

^ [0068] Many variations ol this 4-party design are possible. A principle one is shown in Figure 4 This varialion has 
the eanoe four steps as the Isasic design, but the authorfzation token is seni directly from liho issuer gateway to ihg 
merchanl. Specifically: 

1. In Rgure 4 path 220 the consumer uses a browser to shop at a imerchant WWW site. The consumer presses 
40 a •pay" burton on the merchanrs HTML page, or otherwise indicates they are ready to make a payment. In Figure 
4, path 222. the Merchanl sends a wallet initiatiQn message lo the consumer, containing paymeni amount order 
descrlpilon, timesianp, a random nonce, and possible additional data depending upon requiiemenis. The mer- 
chant signs this initiation n»e$^ge and includes a digital c^rtilicaie provided by the acquiring bank. 

*5 2. In Figure 4, path 224, Ihe Wallet mltotion message causes the consumer'^ browser to start the cor*sumer's 

wallet The consumer is prompted to logon to the wallet using usend/pflssewoid: smartcard, or other appropriate 
authent leal ion nr^chanism Wallet sends data from step 1 . plus the consumer's identity and authentication data lo 
Ihe issuer gateway. 

50 a In Figure 4. path 402 the Issuer gateway verifies the merchant's eignalure and digital certificate lo validaie that 
the merchanl and issuer share a common financial arrangement established 1:^ national law or a financial asso- 
ciation such as MasterCard. Visa, an ATM network or similar organization. The bsuer gateway authorizes payment 
via Ihe issuer's credit card processing system. The issuer gateway generates and sends a signed authorizaiion 
lokai directly lo the merchanl. along with the issuer gateway's oertilicale. The authorization lok^ contains the 

&5 data Irom step 1 plus a merchant identifier and a reference to the consume rs credit card number, as with the base 
proiocol 

Note that the authonzailon token is "bound" to Ihe particular payment by ths relerenc to ihe consumer's credit 
card numt^en merchant id ntifier, payment amouni, timestamp, and nonce. This means that a specilic author izat on 
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loken is good tor jusl one paynnenl 

4. In Figure 4. paih 402. the merchant verifies bolh the issuer gateway's signature and the data in the author izalior 
loken. No separate reallime authorization is required since Ihe payment is "pre-aulhorized" belore it reaches the 

5 merchant. Merchanl sends ackncrwledgment k^ck to the issuer gateway. 

5. In Figure 4, path 224, 1h9 l«su©f gateway serxte achnowiedge back \o the consumer vvaiiei, which lermnai^e 
so thai normal browsmg can procewt. 

JO 6. In Figure 4. paih 242, al some laier lime, the merchant sulDmits tlie aulhorization loken in a capiure requeei lo 

Ihe acquirer's payment gateway The capture r^quesi tens ihe acquirerto adualiy post ihe charge to the consumer^ 
credS or debit account 

[006^1 The difference between this arvJ Ihe baae design ia that the issuer gateway sends the aulhorization token 
75 direcUy lo the merchant, instead oT relaying it through the eonaumer wallet the prinftary advantage of this design Is that 
it matches a "thin' wailel design by moving responsbility for error recovery lo the issuer gateway The disadvantage 
Is that ine consumer wallet (and hence the consumer ) has less opportunity to be aware of me progress of the payment. 
[OCTOI To recap, the method described heiem applies lo both non-mtei active Internet communications such as email, 
ae well as lo inieractive appicatior^ such as Ihe World Wide Web, and according to the pr^erred errbodimeni includes 
^ the step o1 sending Irom a consumer's computer to an issuer gateway lor an issuing bank, an authonzatiort request 
message containing consumer identity and authenlicaiion infonr^aiion, payment amount, an order description, a I imes- 
tamp. a digiial certificate representing a merchant, and adigiial certificaie represenirg the merchant's acquinngt^ank. 
The merchant's digital certiiicate contains a merchant identifier unique tor ihe acquinng bank, and the acquiring barik*© 
digital certificate contains a bank ideniifler unique among alt banlcs sharing a connmon financial arrangemeni TTils ie 
followed by ihe step of validating at the issuer gateway the merchant's certificate and the acquirer's oeilif icate lo prove 
that the merchant, acquirer, and isauer share a common financial an-angemenl. and then ihe issuer gateway verifies 
the consumer's account and ^sures that funds and^or credit are available to support the payment amount before 
authorizing payment by sending over the inleinel network an aulhorization loken. an issuer's coital cenificate. and a 
relercnce lo Ihe consumer's credit or debit carrl number. The aulhorization token includes the payment amount, order 
^ descriplion, timeslamp, a random nonce, the m erchant identilier ( rem ihe merchanrs digital certificate, and the acqu I ring 
bank identifier Irom the acquiring banK^ digital certificate, plusa reference to the consumer's credit or debil card number 
and IS digitally signed by the issuing bank. The merchant's computer receives the authoriz»uon token arvd fulfils the 
order descriplion 

[0071 1 The method nrkay optionally include sertdmg Irom a merchant's computer over an miemei network to a con- 
^ sumer^ computer, a merchant message including a wallet iniieiion message, a merchant digital certBicate. and a 
djgilal certiiicate from an acquiring bank, the watlei m Itiatton message including a paymeni amount, an order description, 
and a timeslamp. A consunner's wallet program in the consumer's computer is atarted in response to the wallet initiation 
message, and then the consunter'a wallet program sends the authorization request message. 
[007!2| The wallet initiation nrtee&age may include a merchant's digital eigna lure in the authorization request message, 
with the issuer gateway verifying the merchant's signature lo prove that the consumer is dealing wiih the actual mer- 
chant. 

[0073| The merchant's computer can perlorm ihe steps of receiving the authorization token, verifying the Issuer's 
signature, digital certirtcate, the paymeni amount and merchant ideniny m the authorization token^ veritymg ihe iresh- 
noss ol the authonzation loken via the limestamp m the loken^ using ihe norwe in the aulhorization token to recognize 

^ dupbcaie tokens, and f ullilling the orde r descript iori. 

[00741 The merchant is able lo claim payment through ihe acquiring bank by forwarding the cuslomer reference 
number and payment amount to the acqumng bank In the case of a subsequent dispute, the merchant proves payment 
authorization by submitting a copy of the auihorizaiton token and issuer's digital certiiicate to the acquiring bank The 
acquiring bank verifies the issuer's signature on the authorization token vaKdates the issuer's digital certfficale, checks 

50 for dupBcales via the timeslamp in the authorization token, and then the acquiring bank pays the amount indicated in 
the authorization loken. 

[0075| The aulhorization request message and aulhorization loken can include a hash of an order description instead 
of the actual order description, the order descriplion itself being available separately al the merchant, the merchant 
validating that the authorization loken relers to the same order descriplion by corrtparlng the hash of the order descnp- 
« tion in the authonzaivn token against a localiy-compuied hash ol ihe same order description 
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Claims 

1. A method tor pei forming eleclronic Iransaclions over a computer network, comprising: 

^ sending Ircm a merchant's computer (204) over an inleinet nelwork lo a consumer'e computer (202), a mer- 

chant message including a wallet Imilaim message (222). a nrterchant dtglia) signature, and adtgllai certificaie 
iroman acquiring bank (208), said waliei initiation me^gainclucling a payment amouni. an order descnptioH: 
arx:! a iimeslamp: (step 304) 

starting s coneumsr's waD9t program m said consurner'e compuier m raspones to «a»d wallet initiation mes- 
to sage: 

sending from sad consumer's compuier consumer identify and authentication information and said merchant 
message, to an issuer gateway (214) for an issuing bank (212): 

verifying at eaid iaeuer gateway said meicham's signature to prove that the condumer is deaiing with ihe adua I 
rrtenchant and validating at eaid issuer gateway the merchant's certificate and the acquirer's eertrficate to prove 
lhai the merchant and Iseuer share a common financia! arrangenteni, 

said issuer gateway verifying the consumer's account and ensuring that funds andA^r credit are av/ailable to 
support the payment amount (step 30dX men authorizing payment by sending over said internet network an 
authorization token (254). an Issuer's digital certificate, said vwallet initiation roessage. and a reference (232*) 
10 eaid consunner's credit (250) or detail card number C^lep 3l0) 
^ said avthorizatlon token including the paynient amount, order deecnpiion. timesismp, a random nonce plus a 

merchant identifier and a reference lo the coneumer'e credit or debit card number; and 
said merdiant's computer receiving said autlionzaiion token and fulfilling said order description 

2. "Rie method of claim t, which further comprises- 

^ sending from said consumer's computer a etart meseage (200) over the internet network to the merchant's 

computer, lo inlilate said merxrhant's message. 

3. The method of claim l or 2 wherein said wallet initiation message includes a nonce. 

^ 4. The method of da Im 1 , 2 or 3. wherein said merchant's computer further perlorms the steps comprising, 
receiving said authorization token; 

verily mg the iseuer's signature, digital cenificale, the payment annount and msfchant identity in the authonza- 
llon token: 

^ verily mg the Ire^ess ot the authorization token via the limestamp in the token: 

using the nonce in the authorization token to recognize duplicaie tokens; and 
fulfilling eaid order description. 

The method ol any of claims l to 4. wherein said consumer identity and authentication Information is a userid and 
^ a password. 

& The method ol any preceding da Im . wherein said issue r gateway sends fiald authorization token to said consumer, 
and tho consumer forwards eaid authonzaiion token to said merchant. 

4S 7. The mothod o* any of clainna i to 5. whereri sakJ issuer gateway sends said authorization token directly to said 
merchant. 

& THe method ot any preceding claim, wherein sak) reference to said credit card is a consumer credit or a debit 
account number. 

so 

9. The method of any of claims 1 to 7, wherein said reference to said credit card is an aGae card number that is 
mapped at the issuing bank to the real card number, thereby preventing use ot the consumer's credit card number 
without said authorization token. 

55 10. The method of any of claims 1 to 7, wherein said relerence lo said catd is an authonzaiion number aikxated 
uniquely by the issuer gateway for each authorization, enabling il to be passed by an acquirer gateway back to 
the issuing Isank m a capture message {256) : 

said issuing bank maintaining a database mapping auihorizanon numbers lo card numbers, so that when 



14 



I 



I 



JO 



EP 1017 030 A2 

Ihe bsuing bank receives ihe capture message, it uses ihe database rnapping to delermine the consumer'e card 
r^unnbeL 

11. The method of any pidceding claim wherein said aulhori2atkn token includes a dunniny card number for u&e in 
louling payment to an appropriate one o1 a plurality of issuing banks <21 2A - 2l 2C), 

3£ild dummy card number being shared among all cardhoMers of a particular Issuing bank. 

12. The meihod of any preceding clamn, wherein *plit shipmeni« are supporled by an additional message intecaclioo 
between ihe merchant and issuer gateway; comprising* 



th« merchant sending ihe auihorizaiion token to ihe issuer gateway identrfied m the issuer's digiial certiiicaie. 
including details of a split requirement, such as Ihe amount of a first payment, the merchani authentcaiing 
Ihe request by algning ii and including the merchant's digital cenificate. 

the issuer gate^ray verifying thai the merchant signing rviessage is the same merchant that signed an original 
request verifying the epiii request according to business and risk management policies, and responding with 
a new authorization token in a message lo the merchant 

Ihe merchant lorwarding the new auihori2aion loksn n a capture message the aoqulr&r gateway. 

Ihe merchant resubmiitrng the new authorization token lo Ihe acquirer gateway in a second message, when- 

everth© merchant has shipped a second pari c/t the shipment, 

The method of any precedmg ciavna, wherein Japanese Payment Opik)ns are provided, compnsmg: 

Ihe iss^uer offering special peyment arrangements to ihe consumer, condnionod on ih© merchant nsme from 
Ihe merchani's digilai certiitcaie and the amount cf payment from Ihe iniiiaiion message 

14 The method of any preceding claim wherein said acquiring bank's digilat certificate contains a network address 
or URL that identifies the network locaiion of saki acquiring bank coniacted via an internet network as pan of a 
payment proiocoL 

15. Tl% ntethod of any preceding claim, wherem sari issuer's digrtat ceitifcaie contains a network address or URL 
» thai identilies the network location ot the Issuer coniacted via an rternel network as part ol a payment protocol 

16. A eystem for perionning electronic iransaotione over a computer network, compnelrig- 

a merchant's computer (204) lor sending over an mtemei network lo a consunrter's computer (202), a merchant 
^ message including a wallet inrtalion message (222K a merchant digital signalure, and a digital certificale from 

an acquiring bank (206), said wallet tniHaiion nrtessage including a payment amount, an order deecrjpiion. and 
a tin^&lamp, 

a consunoer's wallet program in said consumer's computer responsive to sakI waJlei ■nitiaikn message, tor 
s^cfing from &aid consumer's computer consumer identity and authenlicalbn information and said merchant 
40 message, to an issuer gateway (214) for an fesuing bank (2i 2), 

an issuer gateway for verifying said merchani's signature to prove that the consumer is dealing with the adual 
merchani and validating at said issuer gateway me merchani's certificate and the acq ulrer's certificate to prove 
ihat the merchant and Issuer share a common ImarKial arrangement: 

said issuer gateway verifying the consumer's account and ensuring that funds andA>r credit are available lo 
support Ihe payment amount, I hen authon^ing payment by sending over ee id internet network an avthorizai ion 
token (254), an issuer's digiial certilicaie, sanj wallet mitiauon message, and a reference (252') ic said con- 
sumer's credit C2501 ordebii card number 

said authorization token including the payment amount, order description, timestamp. a random nonce plus a 
merchani identiner and a reference lo the consumer's credit or debit card number and 
^ aaid merchant's computer receiving said authorizaUon token and fulfilling said ortier description. 

17. A compuler program product, comprising: 

computer program code means lor sending Irom a merchant's computer (204) over an Internet network lo a 
55 consumers computer (202), a merchant message including a wgilei initiation message {222)., a merchant 

digital signature, and a digital certifk;ate Irom an acquinng bank (203), said wallei mutation message including 
a payrrwt amount, an order description, and a limestamp: 

computer program code means for starting a consumer's wallet program in said consumer's computer in re- 
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sponse to aaid wallel initiation message: 

computer program code means for sending from said consumer's compuler consumer idenlily and authenli- 
calion informaiion and said merchant message, to an issuer gateway (2l4) for an issuing bank (212), 
computer pwogram code means for veiifying al said issuer galeway said merchant's signature lo prove that 
5 ihe consumer is dealing vvith the aciual merchant and vaiidaiing ai said issuer galeway ine merchant s cenif- 

icaie and the ac£|Uirer's certilicale lo prove ihal ihe menchanl and Issuer share a common financial arrange- 
ment 

said issuer gateway verifying the consumer'* account and ensuring ihat funds iindA>r credit sre available lo 
. suppori Ihe payment amount, ihenauthonzingpaymeni by sending over eaid internet netwoiKan authorizaiion 
loken (254). an issuer's digiial certilicale. said wallet initiauon meesage, and a reference (252') lo said con- 
sumers credit (250) or debii card number; 

said authorizaiion loken including Ihe payment amount, order descripi ion. timestamp. a random nonce plus a 

merchani identifier and a reference lo (he consumer's credit oi debii card number and 

said merchant's computer receiving said authorizaiion token and fulfilling said cttler descriplion. 

75 

ia A meihod tor peilorming eleclionic iransaclions over a computer network . compiising: 

sending Irom a consumer's compuler (202) to an Issuer galeway (214) lor an tesuing bank (21 2), an autnon- 
2ai w request mee^ge coniammg consumer ideniity and auihenlicetion mfomiation, payment amount an 
^ order descnption, a limestamp, a digiial certificale representing a merclwit, and a digital certilicale represent- 

ing Ihe merchant's acquiring bank; 

said merchant's digital certificale con lainng a merchant idemiJier unique for the acquiring bank (209); 

said acquiring banK'& digiial cenuicaie containing a bank idenlitier unique among all banks shanng a common 

Finarkcial arrangement: 

validating al said isauer galeway the merchanrs certificale and the ^uirer'a certificale lo prove that the 
merchani. acquirer, and issuer share a common financial anangemem; 

eaid issuer gateway verifying the consumer's account and ensuring ihat funds andA&r credit are available lo 
support Ihe payment amount then authorizing paymenl by sending over said internet network an authorizaiion 
loken (254). an issuers digital certdicale. and a reference (252') to said consumer's credit (250) or debit card 
^ number, 

said autliorization token including ihe payment amouni, order descnption, linr«steimp, a random nonce, said 
merchani ideniifler Irom the nterchanf e digital certificate, and said acquiring bank identiber Irom said acquiring 
bank's digital certificale. plus a reference lo the coneumer's credit or debit card number: 
said auihorization loken being digiiaity signed by the issuing bank: and 
^ said merchant's computer receiving said authorizaiion token and fulfilling said order descriplion 

1ft The melhod cS claim 18. which fuither contprbes. sending Irom a merchanl'e compiiler over an inlernet network 
loa consumer's compuler a nnerchant nnessage including a wallet iniiiaiion message, a merchant digital certricaie, 
and a digital c^tificaie fnom an acquiring bank, said wallel initiation nnesaage inclucfing a paymenl amouni. an 
^ order description, and a limestamp. 

starting a consumer's wanet program n said consumer's computer m response to said wallet initiation mes- 
sage: 

said consumer's v»allei program sending the authorization request message. 

4$ 

20. The melhod of ciaim 19, which further comprises- 

including wiih the wallet initiation message a merchants digital signaiure of the wallet iniiiaiion message: 
including ihe wallel iniliation message and said merchant's digital signature in the authorizaiion requesl mes- 
so aage, 

verifying at said issuer galeway said menehanl's signature to prove that the consumer ia dealing wiih the aciual 
merchani. 

21. The melhod ol any ol claims 13 lo 20, wherein the merchant claims payment through the acquiring bank by for- 
k's waiding the cusionDer relerence number and (sayment amount to ihe acquiring bank. 

22. The melhod cJ any ol clams 16 to 21, wherein the merchant claims payment through the acquiring bank by for- 
waiding the authorization loken and issuer's digiial certilicale to ihe acquiring banK; 
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the acquiring bank verifying ihe issuer's signature on ihe authorization token, \falidating ihe issuer's digilal 
certrficate checking tor duplicates via the limestarnp in Ihe aulhorizaiton loken: and the acquiring bank paying the 
amount indicated in the authorization token. 

23w The method d any ol claints 1 8 lo 22. vuherein said aulhoiization request message and authorization token includes 
a hash ol an order dedcnption Instead ol the actual order descnplbn. the order description Itself being available 
aeparaiely at ihe merchant, the nr^ercharit validating that the authorization token ret et s io the ^me order description 
by companng the h^sh ol ihe order de$crv>tion m the authorizailoo loken againsi a kkC^Hycompuied hash ol the 
same order description 

24. The method ol any of claims 1 8 lo 23. wherem theconiidenilaiity of said credit or detail account number is maintained 
by using a higher-level security protocol, such as encrypled email or SSL, lo protect the comnrujnicalions among 
Ihe consumer and the issuer gateway the consumer and the merchant, the issuer gateway and the merchant, 
and, if applicable the merchant and the acquirer. 
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